Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

CHAPTER 11
Optimization

Optimization and bug proofing are often conflicting goals. Code designed for speed and efficiency is often harder to test and debug than code written for readability. Many programmers are more than happy to make a program illegible and impossible to debug in the name of efficiency.

This chapter does not explain specific techniques for optimizing a program’s performance. It does describe some techniques you can use to make optimization safer. Following these guidelines, you can optimize your Visual Basic program and still keep it readable and relatively bug free.

Note that these optimizations apply to compiled executables in Visual Basic 5 and 6. If you are running an earlier version, you can skip this chapter.

Optimize Algorithms

Optimize algorithms on a large scale instead of individual lines of code. Small changes to a routine will probably not produce large improvements. After spending a lot of effort rewriting and debugging a few key lines of code in a subroutine, you might realize a few percent improvement in speed. On the other hand, changing the fundamental algorithm might make the routine orders of magnitude faster.

Modifying a few lines here and there is also likely to introduce bugs. When you rewrite an entire routine, you need to understand the routine’s purpose and underlying approach. You cannot even begin until you have a reasonable understanding of the routine. On the other hand, it is easy to rewrite a single line of code without understanding the larger context. In that case, you are much more likely to make a seemingly innocuous change that interacts badly with some other code that you do not fully understand.

None of this means that you need to code stupidly and skip obvious chances to improve the code. If there is a more efficient way to write a particular routine, by all means, use it. Do not spend a huge amount of time perfecting every line of code, however. Initially concentrate on making the code easy to understand and modify. You can always change it later if necessary.

Defer Optimization

Near the beginning of a project, focus on getting the program running correctly. Concentrate on writing clear, straightforward code that will be easy to test, debug, and maintain over time. Do not spend time optimizing the code until later.

Usually, more than 95 percent of a program’s time is spent in less than 5 percent of the code. Once you have the program running correctly, you can identify the 5 percent that is most time consuming and concentrate your optimization efforts there. That will probably produce a much bigger improvement in performance than scattering your optimization efforts throughout the 95 percent of the code that is already fast enough.

Concentrating on writing code that is easy to debug also gives you a solid foundation to build on during optimization. If the code is robust and bug resistant, you can concentrate on optimization without wasting huge amounts of time chasing bugs.

Optimize as late as possible. Get the program running bug free first.

Profile First

Before you start optimizing, profile the program’s execution. See how long the program spends in each routine and determine where it spends most of its time. You can use a profiling tool like the Visual Basic Code Profiler described in Chapter 15, “Profiling.” You can also perform tests using the Timer function. For example, the following code prints the time spent in each of three subroutines into the Debug window.

Private Sub LoadData()
Dim start_time As Single
Dim stop_time As Single
Dim fnum As Integer

    ‘ Open the file.
    fnum = FreeFile
    Open “C:\City.dat” For Input As Fnum

    ‘ Read the header information.
    start_time = Timer
    LoadHeader fnum
    stop_time = Timer
    Debug.Print “LoadHeader: ” & _
    Format$(stop_time - start_time, “0.00”)

    ‘ Read the node information.
    start_time = Timer
    LoadNodes fnum
    stop_time = Timer
    Debug.Print “LoadNodes: ” & _
    Format$(stop_time - start_time, “0.00”)

    ‘ Read the link information.
    start_time = Timer
    LoadLinks fnum
    stop_time = Timer
    Debug.Print “LoadLinks: ” & _
    Format$(stop_time - start_time, “0.00”)
End Sub

Once you have profiled the code, identify the routines that take up most of the program’s time. Some you will be unable to improve significantly. For example, a routine that downloads data over a slow modem line will be slow no matter how efficiently you rewrite the code. Focus on code where you can make a meaningful difference.

Comment Optimizations

Many programmers do not add comments when they modify code to improve its performance. They think, particularly near the end of the project, that optimization is more important than clarity.

By adding comments to the code as you optimize it, you can have both speed and clarity. When you change the code, document the change. If the new code is complex, explain how it works. If the old code is easier to understand, comment it out instead of removing it. Then, later developers can compare the two versions of the code.

Whether you modify the code to fix a bug, add a new feature, or to optimize, modifying code is more likely to produce bugs than writing original code is. Treat optimization as bug fixing and use comments to document the changes.

Use Slow Debugging Code

It does not matter how slow debugging code is as long as it is tolerable to the developers. If the code will be removed by compiler constants in the final version, it need only be fast enough to be usable during design and debugging. Do not waste time optimizing code that will be eliminated from the final program anyway. Spend extra time optimizing the debugging code only if it is so inefficient that it is slowing down development.

Be sure you disable the debugging code before you profile the program to find the 5 percent of the code that uses 95 percent of the program’s time. If you generate timing statistics with the debug code running, you will not be able to tell which code really needs optimization.